TRANSFORMATIONAL CONVERSATION DEFINITION 

LANGUAGE 



1 Technical Field 

2 The present invention generally relates to computer languages and, more 

3 particularly to a computer language for facilitating communication between web services, 

4 where web services may use disparate input and output document formats. 

5 Background 

6 Distributed computing has evolved from intra-enterprise application integration, 

7 where application developers work together to develop and code to agreed upon method 

8 interfaces, to inter-enterprise integration, where E-Services may be developed by 
""-^ 9 independent enterprises with completely disjoint computing infrastructures. To 



ihj 10 accommodate the change, E-Services, which may include services, agents, and web- 

2 1 1 services, should be able to communicate and exchmige business data in a meaningful 

'fi 12 way, and have some degree of flexibility and autonomy with regard to tiie interactions. 

13 Several existing agent systems allow services/agents to communicate following 

!^ 14 conversational protocols. However, all of these agent systems are tightly coupled to 

^ 1 5 specific service/agent systems, and require that all participating entities be built upon a 

1 6 common service/agent platform. 

17 Peer-to-Peer (P2P) technology brings distributed computing capabilities to 

18 individuals, creating a new perspective of network-capable devices in the role of 

1 9 resources that can be combined to enable new capabilities greater than the sum of the 

20 parts. As services become more loosely coupled and increasingly autonomous, 

21 heterogeneous distributed services should be able to discover and converse with each 

22 other dynamically, with or without human intervention. Current paradigms of service 

23 interaction, however, require service developers to hardcode their logic to adhere strictly 

24 to pre-defined conversation policies. 

25 For example, Bradshaw, J.M, provides an open distributed architecture for 

26 software agents, e.g., the Knowledgeable Agent-oriented System (KAoS), in the 1996 

27 issue of "Knowledge Acquisition for Knowledge-Based Systems Workshop," entitled 

28 "KAoS: An Open Agent Architecture Supporting Reuse, Interoperability, and 

29 Extensibility." However, as with other conventional techniques, KAoS requires agent 

30 developers to hard-wire conversation policies into agents in advance. 
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1 Walker, A. and Wooldridge, M. address the issue of how a group of autonomous 

2 agents can reach a global agreement on conversation policy in the 1995 issue of "First 

3 International Conference on Multi-Agent Systems " entitled "Understanding The 

4 Emergence Of Conventions In Multi-Agent Systems." However, Walker and Wooldridge 

5 require the agents themselves to implement strategies and control. 

6 Chen, Q., Dayal, U., Hsu, M., and Griss, M. provide a framework in which agents 

7 can dynamically load conversation policies from one-another in the 2000 issue of "First 

8 International Conference on E-Commerce and Web-Technology," entitled "Dynamic 

9 Agents, Workflow and XML for E-Commerce Automation." But the solution of Chen et 

10 al. is homogeneous and requires that agents be built upon a common infrastructure. 

1 1 A few E-Commerce systems also support conversations between services. 

12 However, these systems all require that the client and service developers implement 

13 matching conversation control policies. 

14 For example, RosettaNet's Partner Interface Processes (PIPs) specify roles and 



1 5 required interactions between two businesses, while Commerce XML (cXML) is a 

1 6 proposed standard being developed by more than 50 companies for business-to-business 

17 electronic commerce. However, both RosettaNet and CommerceOne require that 

1 8 participating services pre-conform to their standards. 

19 To illustrate, in an E-Service marketplace with two different enterprises, a client 

20 service in one enterprise may have discovered a storefront service m another enterprise. 

21 In order to complete a sale, a credit validation service in yet another enterprise may be 

22 employed by the storefront service to make sure that the client is credible. These services 

23 can communicate by exchanging messages using common transports and message 

24 formats. The storefront service may expect that message exchanges, i.e., the 

25 conversation, follow a specific pattern. So does the credit validation service. Because the 

26 client and the storefront services belong to different enterprises and have discovered each 

27 other dynamically, tiie client service may not know what conversations the storefront 

28 service supports. Similarly, the credit validation service may not know what 

29 conversations the client service or the storefront service supports. Accordingly, explicit 

30 conversation control implementation may be needed to conduct a conversation between 

3 1 the client service and the storefront service, between the client service and the credit 

32 validation service, and between the storefront service and the credit validation service. 

33 Accordingly, current conversation systems require participating service 

34 developers to implement logic code to adhere strictly to pre-defined conversation policies. 
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1 Should a conversation protocol change, all participating services that support the protocol 

2 must be updated and recompiled, reducing the likelihood that two services that discover 

3 each other will be able to converse spontaneously. 

4 WSCL (Web Services Conversation Language) addresses the problem of how to 

5 enable E-Services from different enterprises to engage in flexible and autonomous, yet 

6 potentially quite complex, business interactions. It adopts an approach from the domain 

7 of software agents, modeling protocols for business interaction as conversation policies, 

8 but extends this approach to exploit the fact that E-Service messages are typically XML- 

9 based business documents and can thus be mapped to XML document types. Each 
10 WSCL specification describes a single type of conversation from the perspective of a 

y 11 single participant. A service can participate in muhiple types of conversations. 

O 12 Furthermore, a service can engage in multiple simultaneous instances of a given type of 

M 13 conversation. However, WSCL does not include any means of specifying document 

"2 14 transformations. 

s 1 5 There are other, similar, business interaction languages, but none of these include 

iff I 16 document tr^isfbrmations. For instance, the Oracle Integration Server, as described by C. 

17 Bussler, "Semantic B2B Integration Server Technology as Infrastructure for Electronic 

1 8 Hubs," First International Workshop on Electronic Business Hubs: XML, Metadata, 
^ 19 Ontologies, and Business Knowledge on the Web (September 2001), includes a semantic 

20 transformation engine for transforming documents, but requires the application 

21 developers to provide explicit docxmient transformations to an intermediary form specific 

22 to the integration server. 

23 Further, the problem of disparate services utilizing different conversation 

24 protocols (flow) is exacerbated by similar conversation protocols using documents that 

25 vary insignificantly. A mere change in a field name can thwart a program from 

26 autonomously managing a conversation between two services. It is therefore desirable to 

27 enable automatic transformation of documents during a conversation. 

28 Summary 

29 It is an aspect of an embodiment of the invention to allow the implementation of 

30 systems that are decentralized and conducive to dynamic and autonomous interactions 

3 1 between applications that have been independently developed with a minimum of 

32 coordination. In particular, an aspect of an embodiment of the invention addresses the 

33 problem of how to enable services that support conflicting message document types to 
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interact in a meaningful way without service developers having to implement any 
document transformation logic. 

A preferred embodiment of the present invention associates document 
transformations with conversation-specific service interactions. Specifically, a 
conversation definition language is extended with document transformational elements or 
specifications, creating a Transformational Conversation Definition Language (TCDL). 

In one embodiment, the TCDL description includes sections for document type 
description defining all inboxmd and outbound documents used in the conversation. The 
TCDL also describes interactions of the conversation, or rather, models the states of the 
conversation. A transition section is included which defines the flow of the conversation, 
or rather, the temporal syntax. The interactions defined in the TCDL are extended with 
transformation definitions to accommodate varying document formats used by different 



services. 



A conversation controller acts as a go-between for two or more services. 
Documents are passed back and forth between two services during a conversation. In one 
embodiment, a document requiring transformations is transformed by the conversation 
controller before being either sent or received by the service requiring transformation. 
The conversation controller uses transfomiations tiiat are put into a common registry by a 
service. In alternative embodiments, more tiian one conversation controller may be used. 

A docviment handler may include deployment descriptors containing mappings 
and/or transformations that are applied to a document, such that the documents may be 
used by the existing business logic of the web service provider. It will be apparent to one 
of ordinary skill in the art that the deployment descriptors may be coded by a TCDL 
programmer for the web service provider depending on the existing code. 
Description Of Drawings 

An exemplary embodiment of the invention is illustrated in the drawings in which 
like numeral references refer to like elements, and wherein: 

FIGURE 1 is a diagram illustrating a comparison of two E-service conversations 

for similar services; 

FIGURE 2 is a block diagram of an exemplary embodiment of a web service 
provider employing the principles of an embodiment of the present invention; 

FIGURE 3 is a block diagram of mi exemplary system employing the principles of 
an embodiment of the invention; and 
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FIGURE 4 is an exemplary XSLT stylesheet showing the transfoiniation required 
to compute an extended jprice according to an embodiment of the invention. 
Detailed Description 

The numerous innovative teachings of the present application will be described 
with particxilar reference to the presently preferred exemplary embodiments. However, it 
should be understood that this class of embodiments provides only a few examples of the 
many advantageous uses of the innovative teachings herein. In general, statements made 
in the specification of the present application do not necessarily delimit any of the various 
claimed inventions. Moreover, some statements may apply to some inventive features but 
not to others. 

There are three elements to a basic WSCL (Web Services Conversation 
Language) specification: 

1 . Document type descriptions specify the types (schemas) of XML 
documents that the service can accept and transmit in the course of a 
conversation. 

2. Interactions model the states of the conversation as document exchanges 
between conversation participants. WSCL currently supports four types 
of interactions: Send (the service sends out an outbound document). 
Receive (the service receives an inbound document), SendReceive (the 
service sends out an outbound document, then expects to receive an 
inbound document in reply), and ReceiveSend (the service receives an 
inbound document and then sends out an outbound document). 

3. Transitions specify the ordering relationships between interactions. A 
transition specifies a source interaction, a destination interaction, and a 
document type that triggers the transition. WSCL 1 .0 also supports two 
special transitions: Default Transition and Exception Transition, A 
default transition is triggered if a valid inbound (for a SendReceive 
interaction) or outbound (for sl ReceiveSend intQiaction) document is 
received for a given interaction, but no other transition is triggered. At 
most one default transition can be defined per source interaction. 

In an exemplary embodiment of the present invention, WSCL is extended with a 
new element, Transformations, that specifies the transformations that can be applied to 
the documents used in the conversation specification. The WSCL Interaction element is 
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1 


then extended with a Transformations subelement that maps the mbound and outbound 




2 


documents to these transformations. This extended language is referred to as 




3 


Transformational Conversation Deiinition Language (TCDL). 




4 


Extending conversation specifications with document transformations frees 




5 


service developers from havmg to navigate between conflictmg document types. This 




6 


completely decouples services from any awareness of document type mismatches - such 




7 


mismatches can be compensated for m the conversation specification. 




8 


In addition, this enables a third-party conversation controller to assume 




9 


•■i.i«<r* Oil , 1 * iiiiii 1* 1 (y 

responsibihty for some of the computational tasks that may be involved m the course oi 


s 


10 


the conversation. For example, the conversation controller could use these 




11 


transformations to route a conversation according to the content (vs. type) oi message 


w 


12 


documents. A preferred conversation controller is described m U.S. Patent Application 


nil 


13 


Ser. No, 09/862,612, (Attorney Docket No, HP 10012649-1), entitled "Lightweight 


14 


Dynamic Service Conversation Controller, ' to Michael J. Lemon, et al., filed on May 23, 




15 


2001, and herein mcorporated by reference m its entirety. It will be apparent to one 




16 


skilled in the art how to extend the preferred conversation controller, or altemative 




17 


conversation controller, to enable document transformation based on the description of 




18 


the present invention herein. 




19 


Referrmg now to the drawmgs, and m particular to FIGURE 1, there are shown 




20 


two shopping cart conversation specifications 101 and 151 for digital photograph 




21 


Storage services (similar to services offered by compames such as ofotoxom). These 




22 


conversations are specified from the perspective of the photo storage service. The circles 




23 


represent interactions, or states; the boxes represent mboxmd document types, and the arcs 




24 


between the circles represent the transitions between interactions, which are driven by 




25 


outbound document types. The two conversations 101 and 151 are structurally similar, 




26 


but not identical. 




27 


The "secure album" conversation 101 requires the client to sign in (login) before 




28 


selecting an album, as shown by the outbound document type loginRS 103 becommg an 




29 


inbound document along with chooseAlbum 105 required for the album selection 




30 


transaction 107. On the other hand, the anonymous guest conversation 151 doesn t 




31 


require the client to sign in (login) until they are ready to purchase some photos, as shown 




32 


by inbound document chooseAlbum 155 to the start transaction 153 which does not 




33 


require a loginRS 103 document. In addition, once tiie client is ready to check out, the 




34 


"secure album" conversation expects the client to send a document of type CheckoutRQ 
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1 1 09 and the server to respond with a document of type Bill 111, while the "anonymous 

2 guest" conversation expects the cUent to send a Requestlnvoice 1 59 document and the 

3 service to respond with an Invoice 161 document. Thus, it can be seen that these two 

4 similar conversations produce either a bill or invoice, respectively, but that the documents 

5 are not identical, 

6 For purposes of this description, a service is loosely defined as an application that 

7 can be discovered and that supports some protocol, so that another application could send 

8 it a message. Thus, there is a discovery mechanism and a protocol. Not necessary for the 

9 present invention, but in an optimal e-service markeQ)lace, a service is modular and self- 

10 contained; services or applications can act as resources to other applications so that they 

1 1 can be performed or scheduled or committed with or without human intervention. 

12 Another optional requirement for a service is that it be a self describing application. In 

13 this way, it can communicate its capabiUties and requirements to other applications 

14 through a pre-defined or standard mechanism or protocol. A service is instrumented so 

15 that an external application management system is able to detect and manage the state of 

16 the service and the status of its outcome. Further, one should be able to broker auction 

17 services, meaning that there should be a marketplace that exists. It will be apparent to 

1 8 one skilled in the art that for the present invention, only the most rudimentary service 

1 9 characteristics must be implemented. It will also be apparent to one skilled in the art that 

20 as E-service technology evolves, additional service characteristics, as listed above, will be 

21 available. 

22 Assuming a marketplace with services that are capable of exchanging mess^es, 

23 service implementers/designers must solve three problems in order to enable the services 

24 to dynamically interact with each other without a human directing them. First, new 

25 services must be capable of being located so services can decide to talk to each other. 

26 Second, services must be able to send messages to each other, that is legal, or allowable, 

27 messages. This is referred to as a message exchange. For example, service A could 

28 accept a login and a login message with the understanding tiiat it will return to the client 

29 either a login-accepted or a login-rejected message. This is a message exchange. Third, 

30 services must be able to automatically transmit and accept messages m a variety of 

3 1 formats because each service may have its own document format. 

32 A conversation is a sequence of message exchanges. For example, the client 

33 sends a login document to Service A. Service A sends a login accepted document to the 

34 client. The cUent then sends a catalog request to Service A. Service A then sends a 
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catalog to the client, etc. A conversation description is a specification that gives a formal 
description, or formal definition, of a set of legal sequences of document exchanges. This 
present invention extends a conversation exchange to include document transformation. 

The messages exchanged by services are assumed to be semi-structured 
documents, for example using XML. The structure for a class of documents is described 
using a schema or some other specification. Because the documents are structured or 
semi-structured, a transformation fi*om one type of schema to another type of schema can 
be written. In an exemplary embodiment, a transformation is necessary to transform a 
document of type loginj-equest to type signjnj-equest. The difference between the two 
documents might be very simple. For example, the loginj-equest document might expect 
a "login" field, whereas a signj,n_request expects a "user_name" field or the similar. 
Message and commimication protocols typically require header information to be sent 
along with the data. Specifically, XML messages basically have a header that identifies 
the type of the object that is being sent. Therefore, even though in an abstract level, the 
"login" and "user_name" fields hold the same data, the messages will be sent with 
headers that label the data differently. Thus, even if the data is identical, without an 
appropriate transformation, the message will be rejected if it contains an alternative 
header. 

A model for web communication is that web services publish information about 
the specification that they support. UDDI (Universal Description Discovery and 
Integration) facilitates the publication and discovery of web service information. A 
current version of WSDL (Web Service Definition Language 1.0) is an XML-based 
format that describes the interfaces and protocol bindings of web service fimctional 
endpoints. WSDL also defines the payload that is exchanged using a specific messaging 
protocol; Simple Object Access Protocol (SOAP) is one such possible protocol. 

A Conversation Design Language (CDL), as described in U.S. Provisional Patent 
Application Serial No. 60/253,953, (Attorney Docket No. HP 10010485-1), entitled "A 
Computer Language for Defining Business Conversations," to Alan Karp, et al., filed on 
Nov. 28, 2000, and herein incorporated by reference in its entirety, enables web services 
provided by different entities to engage in flexible and autonomous interactions. For 
example, supposing a client web service in one business discovers a storefront web 
service provided by another business. These services can communicate by exchanging 
messages using a common transport (e.g., HTTP) and message format (e.g., SOAP). 
However, also suppose that the storefi*ont service expects the message exchanges to 
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1 follow a specific pattern (conversation), CDL may be used to define the conversation, 

2 such that the storefiront service may expect a particular message in response to 

3 transmitting a particular message. 

4 Messages exchanged between web services may include XML documents. 

5 Messages may include different types of messages (e.g., types of XML documents), and a 

6 type of message may be described by a schema (e.g., in a registry) and facilitates the 

7 introspection of services and their interfaces. It will be apparent to one of ordinary skill 

8 in the art that messages may be generated using languages other than XML. 

9 An exemplary conversation includes a sequence of exchanges of XML documents 

10 between entities. A TCDL description file includes the sequence of interactions (e.g., 

1 1 transmitting and/or receiving messages) between entities and the XML document types 

12 that may be used in each interaction. Each TCDL description describes a single type of 

13 conversation from the perspective of a single participaut A service can participate in 

14 multiple types of conversations. Furthermore, a service can engage in multiple 

15 simultaneous instances of different conversations. A TCDL programmer may create a 



IfU 16 TCDL description for a conversation , and publish it bi a UDDI-like registry, A 

M 17 developer who wants to create a service that supported a conversation creates and 

p 18 documents service endpoints that support the messages specified by the TCDL 

19 description for that conversation, 

20 FIGURE 2 illustrates an exemplary embodiment of a web service provider 200 

21 employing principles of an embodiment of the invention. The web service provider 200 

22 may publish a TCDL description file 210 in a remote registry, such as registry 3 10 (as 

23 shown in FIGURE 3), storing TCDL description files defining conversations for multiple 

24 service providers. Other web service providers and customers may retrieve the TCDL 

25 description file 210 fi-om the registry, because the TCDL description file 210 defines a 

26 conversation for interacting with the web service provider 200 to facilitate business-to- 

27 business transactions and customer-to-business transactions with the web service provider 

28 200. Further, the TCDL description file defines valid docviment transformations and 

29 identifies locations of appropriate schema documents, 

30 Instead of, or in addition to TCDL description files, the registry 310 may include a 

31 list of CDL description files used by each service provider, e.g^., a TCDL description file 

32 without any transformations defined. For example, a user may store a plurality of 

33 CDL/TCDL description files for communicating with miiltiple web service providers. 

34 The user may access the registry 3 10 to identify the CDL/TCDL description file used by a 
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specific web service provider. Then the user, already having the identified CDL/TCDL 
description file, uses the identified CDL/TCDL file to communicate with the web service 
provider. Furthermore, the user may not need to access the registry if the user knows 
which CDL/TCDL description files is used by this service provider. This allows a 
service provider to conmiunicate with other services using transformation if a TCDL file 
is available, but to also communicate vrtth a service provider without transformation if 
only a CDL file is available and inbound and outbound documents are valid without 
transformation. 

In one embodiment, the web service provider 200 compiles the TCDL description 
file 210 to generate a conversation controller 220 (e.g,, an executable computer program). 
The conversation controller 220 may transmit and receive XML documents 230 and 
generate error messages based on the TCDL description file 210. A document handler 
240 may include deployment descriptors containing mappings and/or transformations that 
are applied to the XML document 230, such that the XML documents 230 may be used 
by the existing business logic 250 of the web service provider 200. It will be apparent to 
one of ordinary skill in the art that the deployment descriptors may be coded by a TCDL 
programmer for the web service provider 200 depending on the existing code. 

The TCDL description file 210 may also be incorporated in a service interface, 
rather than being compiled and executed as a separate program. For example, the TCDL 
description file 210 may be a library or object. 

FIGURE 3 illustrates an exemplary system 300 employing principles of an 
embodiment of the invention. The system 300 embodies an example where a customer 
340 orders items fi-om an entity A (e.g, , a web service provider) providing a web service 
on a computer 320. The entity A sends the order, originating from the customer 340, to a 
supplier (ie., entity B) providing a sales order web service using a computer 330. The 
web services provided by entities A and B may be configured similarly to the web service 
shown in FIGURE 2. 

The entities A and B may be registered in registry 310. The registry 310 may 
include a UDDI-like registry that lists a location, which may include a uniform resource 
identifier (e.g., URL, URN, and the like) for each CDL/TCDL description file provided 
by the entities A and B. In addition to or alternatively, the registry 310 may include a list 
of CDL/TCDL description files used by entities A and B. Therefore, a user or web 
service provider that desires to communicate with entity A or entity B may access the 
registry to determine which CDL/TCDL description file is used by the entity. The 



HP10018402-1 



10 





1 


registry 310 may be accessed through a global computer network, i.e.^ me Internet, and or 




2 


through private networks, z,e., intranets or extranets. Entities, including customers. 




3 


businesses, and the like, may access the registry 3 10 to identify web services provided by 




4 


each other. For example, the customer 340 may identify the purchase order service 




5 


provided by the entity A, and entity A may identify the sales order service provided by 




6 


the entity B through the registry 310. 




7 


The customer 340 may utilize a computer 345 executing a TCDL client 347 that 




8 


exchanges documents with a purchase order conversation controller 325 m the computer 




9 


320. The TCDL client 347 may retrieve the URL (e.g., http://www,entityAxoni/po) of 


ib 


10 


the purchase order conversation controller 325. The interactions between customer j40 




11 


and the entity A may include transmit/receive purchase order, receive invoice, transmit 




12 


payment, and the like. 




13 


The entity A may retrieve the URL (e.^,. http://www.entitYB.com/sales) for the 




14 


sales order controller 332. Entity A and the entity B may then engage m a conversation to 




15 


facilitate a purchase from the entity B. The mteractions between entity A and the entity B 




16 


may include transmit price proposed, receive price accepted, receive price rejected, 




17 


receive invoice, transmit receipt, and the like. 




18 


The computer 320 and the computer 330 may include web servers providing a 




19 


service over the Internet , and the computer 345 may include a conventional device 




20 


configured to communicate over the Internet and/or other networks. It will be apparent to 




21 


one of ordinary skill in the art that the system 300 is functional to provide other services 




22 


to one or more entities, which may include one or more customers, businesses, and the 




23 


like. 




24 


Web services communicate with each other through the exchange of documents. 




25 


and a TCDL conversation description defines all the inbound and outbound document 




26 


types that may be used in the conversation using document type descriptions, as well as 




27 


interactions, transformations and transitions. A document type description may refer to a 




28 


schema (e.g., an XML schema, and the like) that includes attributes (e.g., data, types, and 




29 


the like) of a particular document type. A document (e.g., an XML document, and the 




30 


like) of a particular document type includes an instance of the attributes included in the 




31 


schema for that document type. The schemas of the docviments exchanged during a 




32 


conversation are not specijSed as part of the CDL specification. The actual document 




33 


schemas may be defined in XML documents that can be referenced by their URL or URN 




34 


in the interaction elements of the conversation specification. For example, the following 
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1 document type description defines an input document (/. e. , inbound XML document) that 

2 conforms to a purchase order schema defined in a file named billOJSales.xsd, where the 

3 extension "xsd" indicates an XML schema document. 

4 <InboundXMLDocuinents> 

5 < I nboundXML Document 

6 href Schema="http : / /convl23 . org/billOf Sales . xsd" 

7 id="billOf Sales "> 

8 </InboundXMLDocument> 

9 < / InboundXMLDocument s> 

1 0 The following document type description defines an output document (i, e, , 

^ 1 1 outbound XML document) that conforms to a purchase order schema defined in a file 

^ 12 ndim&dipaymentDetails.xsd. 

if^ 13 <OutboundXMLDocuments> 
to 14 <OutboundXMLDocument 

15 href Schema="http: //convl23 . org /paymentDetails . xsd" 

]M 16 id="paymentDetails"> 

17 </OutboundXMLDocuinent> 

18 </OutboundXMLDocuments> 

y 

0 19 00 

g 20 Suppose that entity A uses documents of the type biHOfSales, but that entity B 

^ 21 uses a similar document type of paymentRequest. Without the ability to transform one 

22 document type into the other, one cannot commimicate autonomously between the two 

23 entities. The present invention extends the document type description to include a 

24 transformations attribute. 

25 Suppose there were an XSLT stylesheet, paymentRequest2binOfSales, that could 

26 transform a paymentRequest document into the document type billOfSales, and another 

27 stylesheet, paymentResponse2paymentDetails that could transform a paymentResponse 

28 document into type paymentDetails. The following XML code is a TCDL representation 

29 of the Transformations element of the specification for Conversation 151 (as shown in 

30 FIGURE 1). It will be apparent to one of ordinary skill in the art that TCDL is not tied to 

3 1 any particular transformation specification, XSLT is used for exemplary purposes. 

32 <Transf orinations> 

33 <Transformati on id="payinentRequest2billOf Sales"> 

34 <href="http: //convl23.org/paymentRequest2billOf Sales. xsl"/> 

35 < InboundXMLDocument 

36 href Schema="http: //convl23 . org/paymentRequest . xsd"/> 

37 <OutboundXMLDocuinent 
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1 href Schema="http : //convl23 . org/billOf Sales . xsd"/> 

2 </Trans format ion> 

3 <Transf ormation id="payinentResponse2payinentDetails"> 

4 <href ="http : //convl23 . org/ paymentResponse2payinentDetails . xsl"/> 

5 < I nboundXML Document 

6 href Schema="http: //convl23 . org/paymentResponse . xsd"/> 

7 <OutboundXMLDocument 

8 href Schema="http: //convl23 . org/paymentDetails . xsd"/> 

9 </Transf ormation> 

10 </Transf ormations> 

1 1 The TCDL above describes the ability for a service to transform a check out 

12 request into a request invoice, or in tiie terminology of the services, a "paymentRequesf 
g 13 to a "billOfSales". The URL for the transformation XSLT stylesheet is defined in 

IItJ 14 <href-"http; //convl23 . org/paymentRequest2billOf Sales . xsl"/>, as shown in 

y 15 the transformation id attribute. The transformation is associated with an inbound 

J 16 document 

17 <InboundXMLDocument href Schema="http : //convl23 . org/paymentRequest . xsd"/> 

18 which is transformed into an outbound document 

S 19 <OutboundXMLDocument href Schema="http : //convl23 . org/billOf Sales .xsd"/>. 

w 

^ 20 The TCDL above also describes the ability for a service to transform a payment 

21 response into a payment details document. The URL for the transformation XSLT 

22 stylesheet is defined in 

23 <href="http: //convl23 . org/paymentResponse2paymentDetails . xsl"/>5 as shown 

24 in the transformation id attribute. The transformation is associated with an inboxmd 

25 document 

26 <InboundXMLDocument href Schema="http : //convl23 . org/paymentResponse . xsd"/> 

27 which is transformed into an outbound document 

28 <OutboundXMLDocument href Schema="http: //convl23 , org/paymentDetails . xsd"/> . 

29 The following is an instance of using TCDL to couple the transformation with the 

30 interaction. Interaction describes the message exchange. Inbound XML document 

3 1 describes the message that is coming in and outbound describes the message that is going 

32 out. The interaction section of the TCDL defines, for a particxilar state, that an input bill 

33 of sales document is expected to be received. It expects to then put as output a payment 

34 details document. The extension is the transformation element which defines the 

35 application of the payment request to bill of sales transformation to an inbound document. 

36 Similarly the payment response to payment details transformation can be applied to the 
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1 outgoing document, if necessary. It will be apparent to one of ordinary skill in the art that 

2 while the exemplary embodiment shows one transformation for one type of inbound 

3 document, e.g. , billOfSales, and one type of outbound document, e.g. , paymentDetails, 

4 that many transformations could be defined for any of several inbound or outbound 

5 documents. These transformations are added to an exemplary extended TCDL 

6 interaction, as shown below. 

7 <Interaction StepType="ReceiveSend" id="payment" initialStep="f alse"> 

8 < I nb oundXMLDo cumen t s > 

9 <InboundXMLDocument 

10 href Schema=http : //convl23 , org/billOf Sales . xsd 

11 id="billOfSales"> 
■:L^ 12 <Transf ormations> 

S 13 <Transforitiation id=''paymentRequest2billOf Sales"/> 

14 </Transf ormations> 



JIT; 15 </InboundXMLDocument> 
,^ 16 </InboundXMLDocuments> 
^ 17 <OutboundXMLDocuments> 
IJ^ 18 <OutboundXMLDocument 

m 19 href Schema="http : //convl23.org/payinentDetails. xsd" 

'•: 

^ 20 id="paymentDetails"> 

21 <Trans format ions> 

%^ 22 <Trans formation id="paymentResponse2paymentDetails'V> 

23 </Trans format ions> 

24 </OutboundXMLDocument> 

25 < / Ou t boundXMLDo cume nt s > 

26 </Interaction> 

27 For each state a piece of XML code (TCDL) is provided that describes the schema 

28 that describes the data and the transformations that could be used to change the document 

29 format used by one service to the document format of another service. TCDL specifies 

30 the valid inbound and outbound documents for an interaction, it does not specify how the 

3 1 conversation participants will handle and produce these docxmients. The TCDL 

32 specification of a conversation is thus service-independent, and can be used (and reused) 

33 by any number of services. Further, the ordering among interactions is specified in a 

34 transitions section of the TCDL, and is not relevant to the transformation definitions 

3 5 because regardless of the form of conversation navigated to reach a state, or interaction, 

36 that interaction is defined to utilize a specific set of inbound and outbound documents, 

37 each of a given format. 
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1 


In another exemplary embodiment, a client shops for grocery items using a 




2 


service. An XML description for a shopping list document for Service A might look like 




3 


the following: 




4 


^ Oi A^M*^^ J-i ly J_ _L B L. 




5 


^ rr Y* ri A Y" \7'> 




6 






7 






g 






9 






10 






11 


-<^T^ V* ^ n +" "V^a/^/^io" ^ / "v" /~\ W n *^ 






^ XT'** 1 //-T-l- Tr'N. 

v. qi- y-^ J- ^ / c[ c y> 


6 


13 




jW 


14 








IT ocei. y^ 


uh 


1 u 




;S 


17 


<<5iiy> z </ C5tiy> 




1. o 






19 

J. -7 


^/ y I. vJt-,el. y ^ 




20 


v.yxtJ\_»t3J_y-^ 




21 


<product> "tomato" </product> 


5 


22 


<qty> 3 </qty> 




23 


<unit price> 0.45 </unit price> 




24 


</grocery> 




25 


<;/shopping_list> 




26 


In contrast. Service B may use an extended shopping list document like the 




27 


following^ 






\SXiOppixiy ±-LoL^ 




20 


y XT o ce J. y ^ 






<p2roduct> "bread" < /product > 






<cjii.y>K/ c5i3^y-> 






<unit price>l . 75</unit price> 






^ ^ v^ V" "1 ^ T "7 / A >^ .A v^'v^n \. 

<NexT-enaQQ price-^i. /o^/exLenaea pnce> 






</ girocery^- 




J J 


<grocery> 




36 


<product> "bacon "</product> 




37 


<qty>l</qty> 




38 


<unit_price>6 , 00</unit_price> 




39 


<extended_price>6</ext ended price> 




40 


</grocery> 
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1 <grocery> 

2 <product>"lettuce"</product> 

3 <qty>2</qty> 

4 <unit_price>l . 25</unit_price> 

5 <extended_price>2 . 5</extended_price> 

6 </grocery> 

7 <grocery> 

8 <product>"tomato"</product> 

9 <qty>3</qty> 

10 <unit__price>0 . 45</unit_price> 

1 1 <extended_price>l , 35</extended__price> 

12 </grocery> 

13 </shoppmg_list> 

14 The extended shopping list includes a field extended j)rice which is merely a 

15 calculation of quantity (e.g., qty) and the unit price (e.g. , unit _price). An appropriate 

16 transformation is required if Service A and Service B want to communicate in a 

17 conversation. Further, including a transformation in a stylesheet iised by the conversation 

18 controller allows any computational loads to be transferred to the conversation controller 

1 9 rather than the client site or service provider site. This may be advantageous for 
P 20 transformations with significant computational needs. 

jLj, 21 FIGURE 4 shows an exemplary XSLT stylesheet 400 showing the transformation 

22 required to compute extended jyrice. This exemplary stylesheet 400 has three templates: 

23 shopping^ list 401 , grocery 403, and a common template for product^ qty and unit _price 

24 405. The j'/icp/>7«g //5'/ template 401 applies templates for grocery 5^ The grocery 

25 template 403 applies templates for product, qty and unit j>rice 433, as necessary. The 

26 element extended _price 435 is also defined for template grocery 403. The 

27 extended j?rice element is defined to perform the calculation unit _price * qty. This 

28 stylesheet is used to transform the shopping list above to the extended shopping list. 

29 In an exemplary embodiment a log in document must be transformed into a 

30 sign_in docxmient. A shopper sends a log_in request to a service provider. The 

3 1 conversation conducted between the shopper and the service provider is managed by a 

32 conversation controller/server. The conversation controller determines that the service 

33 provider needs a sign_in document and that a transformation is defined in the TCDL 

34 document corresponding to transformation of a log_in to a sign_in document. This 

35 transformation definition points to an XML schema. The conversation controller 

36 translates the log_in request sent by the shopper to a sign_in request using the XML 
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1 schema for the transformation. The conversation controller then forwards the sign_in 

2 request to the service provider. This entire process is transparent to the user, who is 

3 unaware that any document transformation has taken place. 

4 Having described preferred embodiments of a novel method for extending a 

5 conversation definition language to include document transformation capability (which 

6 are mtended to be illustrative and not limiting), it is noted that modifications and 

7 variations can be made by persons skilled in the art in light of the above teachings. It is 

8 therefore to be understood that changes may be made in the particular embodiments of the 

9 invention disclosed which are within the scope and spirit of the invention as defined by 
10 the appended claims. 
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